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AUTOMATED CLINICAL SYSTEM TO FACILITATE THE PROCESS OF 
PROVIDING NOTICE OF LABORATORY RESULT PUBLICATION 

CROSS-REFERENCE TO RELATED APPLICATIONS 
[0001] This application claims the benefit of U.S. Provisional Patent Application Serial 
No. 60/431,361, filed December 6, 2002 entitled "Automated Clinical System to Facilitate 
the Process of Providing Notice of Laboratory Result Publication" and U.S. Provisional 
Patent Application Serial No. 60/437,833, filed January 3, 2003 entitled "Automated Clinical 
System to Facilitate the Process of Providing Notice of Laboratory Result Publication". 

STATEMENT REGARDING FEDERALLY SPONSORED RESEARCH OR 

DEVELOPMENT 

[0002] Not applicable. 

FIELD OF THE INVENTION 
[0003] The present invention relates to a computer system and, more particularly, to an 
automated computer system to facilitate the process of providing notice of laboratory result 
publication. 

BACKGROUND OF THE INVENTION 
[0004] Laboratories are the backbone supporting the provision of healthcare. As such, 
it is critical that laboratory results are communicated to the care provider in a time sensitive 
and efficient manner. In healthcare information technology systems, once the results are 
received by the system, a standard results publication process communicates the results to the 
relevant physician. The standard results publication process centers around a printed report 
that is reviewed by the doctor at the end of the work day or a similarly convenient time. In 
addition to the standard results publication process, many clinical and pathology laboratories 
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maintain and support a process whereby physicians are notified of certain laboratory results 
in a manner outside of the printed report. In the industry, this process is sometimes termed 
"callback" since the process is typically completed by a laboratory employee placing a phone 
call to contact the doctor to provide notice of results. These laboratories might notify the 
doctor of certain results based on the "normalcy" of the results. For instance, the results may 
be deemed normal, abnormal, high or low. A callback may be required for any results that 
are not normal. In other circumstances, the criticality of the results may be used as the basis 
for determining if a call to the physician is required. In other cases, the parameters around 
the laboratory order rather than the results of the order may serve as the basis for a call to 
occur. For example, information relevant to the ordering physician, ordered procedure, or 
ordered priority may trigger notification. In another example, instead of initiating the call 
based on the order or result, information regarding the assay may be used to determine if a 
call should be made to the physician. 

[0005] Laboratory information systems publish laboratory results to a database 
dedicated to storing laboratory information. As mentioned above, some laboratory 
information systems employ callback systems that notify a user of the system that a callback 
is required based on the callback criteria. Typically, when the call is complete, these callback 
systems receive input from the user documenting the completion of the call. However, many 
laboratory information systems do not have callback systems to notify the user of requests 
requiring callback. These processes rely on people to determine if a callback is required. 

[0006] Also, in order for the callback process to be effective and trusted, a laboratory 
must define and consistently execute the callback commitment made to the physician 
community. If the laboratory agrees to make a phone call to the physician for every critical 
result value (or other value requiring callback based on the relevant criteria), then the 
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laboratory must successfully contact the physician for every critical value reported. If the 
laboratory does not meet the laboratory's commitment to contact the physician community 
for certain types of results, then the laboratory's credibility and trustworthiness are 
compromised. Prior solutions are manual and do not automate the process of notifying the 
physician. As such, these systems suffer from the failures of human memory and execution, 
oftentimes at the cost of patient safety and efficiency. 

SUMMARY OF THE INVENTION 
[0007] The invention overcoming these and other problems in the art relates in one 
regard to a system and method in a computer system for facilitating the computerized process 
of providing notice of laboratory result publication. An automated system solution is 
provided to facilitate the callback process. Laboratory results from a laboratory information 
system (LIS) database are posted to an electronic medical record (EMR) database either 
directly or through an interface. The system creates a callback request for each result that 
needs to be communicated back to the physician. The request may be based on the ordered 
procedure, the resulted assay, or the actual assay results (and associated assay result flags). 
In another embodiment of the system, a system and method for automatically managing the 
handling of callback processes is provided. Additional advantages and novel features of the 
invention will be set forth in part in a description which follows, and in part will become 
apparent to those skilled in the art upon examination of the following, or may be learned by 
practice of the invention. 
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BRIEF DESCRIPTION OF THE DRAWINGS 
[0008] Fig. 1 illustrates an overall architecture in which an automated clinical system 
may operate to facilitate the process of providing notice of laboratory result publication 
according to an embodiment of the invention. 

[0009] Fig. 2 illustrates a flowchart of the overall method for facilitating the process of 
initiating a callback request utilizing an electronic medical record database. 

[0010] Fig. 3 illustrates a flowchart of the overall method for automatically completing 
a callback request to provide notice of laboratory result publication. 

DETAILED DESCRIPTION OF EMBODIMENTS 
[0011] Fig. 1 illustrates an example of a computing system environment 10 in which a 
system and method for facilitating the process of providing notice of laboratory result 
publication, according to an embodiment of the invention. 

[0012] The computing system environment 10 is only one example of a suitable 
computing environment and is not intended to suggest any limitation as to the scope of use or 
functionality of the invention. Neither should the computing environment 10 be interpreted 
as having any dependency or requirement relating to any one or combination of components 
illustrated in the exemplary environment 10. 

[0013] The invention is operational with numerous other general purpose or special 
purpose computing system environments or configurations. Examples of well-known 
computing systems, environments, and/or configurations that may be suitable for use with the 
invention include, but are not limited to, personal computers, server computers, hand-held or 
laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, 
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programmable consumer electronics, network PCs, minicomputers, mainframe computers, 
distributed computing environments that include any of the above systems or devices, and the 
like. 

[0014] The invention may be described in the general context of computer-executable 
instructions, such as program modules, being executed by a computer. Generally, program 
modules include, but are not limited to, routines, programs, objects, components, and data 
structures that perform particular tasks or implement particular abstract data types. The 
invention may also be practiced in distributed computing environments where tasks are 
performed by remote processing devices that are linked through a communications network. 
In a distributed computing environment, program modules may be located in both local and 
remote computer storage media, including memory storage devices. 

[0015] With reference to FIG. 1, an exemplary system for implementing the invention 
includes a general purpose computing device in the form of server 12. Components of server 
12 may include, but are not limited to, a processing unit, internal system memory, and a 
suitable system bus for coupling various system components, having a database cluster 
including an laboratory information system (LIS) database 14 and an electronic medical 
record (EMR) database 15 in communication with the control server 12. The system bus may 
be any of several types of bus structures, including a memory bus or memory controller, a 
peripheral bus, and a local bus using any of a variety of bus architectures. By way of 
example, and not limitation, such architectures include Industry Standard Architecture (ISA) 
bus, Micro Channel Architecture (MCA) bus, Enhanced ISA (EISA) bus, Video Electronic 
Standards Association (VESA) local bus, and Peripheral Component Interconnect (PCI) bus, 
also known as Mezzanine bus. 



* 4 Docket No. CRNC 102452 

[0016] Server 12 typically includes therein or has access to a variety of computer 
readable media, for instance, database cluster 14. Computer readable media can be any 
available media that can be accessed by server 12, and includes both volatile and nonvolatile 
media, removable and nonremovable media. By way of example, and not limitation, 
computer readable media may comprise computer storage media and communication media. 
Computer storage media may be implemented in any method or technology for storage of 
information, such as computer readable instructions, data structures, program modules or 
other data. Computer storage media includes, but is not limited to, RAM, ROM, EEPROM, 
flash memory or other memory technology, CD-ROM, digital versatile disks (DVD), or other 
optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage, or other 
magnetic storage devices, or any other medium which can be used to store the desired 
information and which can be accessed by server 12. Communication media typically 
embodies computer readable instructions, data structures, program modules, or other data in a 
modulated data signal, such as a carrier wave or other transport mechanism, and includes any 
information delivery media. The term "modulated data signal" means a signal that has one or 
more of its characteristics set or changed in such a manner as to encode information in the 
signal. By way of example, and not limitation, communication media includes wired media, 
such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, 
infrared and other wireless media. Combinations of any of the above should also be included 
within the scope of computer readable media. 

[0017] The computer storage media, including database cluster 14, discussed above and 
illustrated in FIG. 1, provide storage of computer readable instructions, data structures, 
program modules, and other data for server 12. Server 12 may operate in a computer network 
16 using logical connections to one or more remote computers 18. Remote computers 18 can 
be located at a variety of locations in a medical or clinical laboratory environment, for 
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example, but not limited to, hospitals, other inpatient settings, and testing labs. The remote 
computers may be physically located in a non-traditional clinical laboratory or medical care 
environments so that the entire health care community is capable of integration on the 
network. Each remote computer 18 may be a personal computer, server, router, a network 
PC, an interfaced instrument, a peer device or other common network node, and may include 
some or all of the elements described above relative to server 12. Computer network 16 may 
be a local area network (LAN) and/or a wide area network (WAN), but may also include 
other networks. Such networking environments are commonplace in offices, enterprise-wide 
computer networks, intranets and the Internet. When utilized in a WAN networking 
environment, server 12 may include a modem or other means for establishing 
communications over the WAN, such as the Internet. In a networked environment, program 
modules or portions thereof may be stored in server 12, or database cluster 14 and 15, or on 
any of the remote computers 18. For example, and not limitation, various application 
programs may reside on the memory associated with any one or all of remote computers 18. 
It will be appreciated that the network connections shown are exemplary and other means of 
establishing a communications link between the computers may be used. 

[0018] By way of example, a user may enter commands and information into server 12 
or convey commands and information to the server 12 via remote computers 18 through input 
devices, such as keyboards or pointing devices, commonly referred to as a mouse, trackball, 
or touch pad. Other input devices may include accepting data from an interface or logic 
system, microphone, satellite dish, scanner or the like. Server 12 and/or remote computers 18 
may have any sort of display device, for instance, a monitor. In addition to a monitor, server 
12 and/or computers 18 may also include other peripheral output devices, such as speakers 
and printers. 
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[0019] Although many other internal components of server 12 and computers 18 are not 
shown, those of ordinary skill in the art will appreciate that such components and their 
interconnection are well known. Accordingly, additional details concerning the internal 
construction of server 12 and computers 18 need not be disclosed in connection with the 
present invention. 

[0020] Although the method and system are described as being implemented in a 
WINDOWS operating system operating in conjunction with a comprehensive healthcare 
network, one skilled in the art would recognize that the method and system can be 
implemented on any system supporting the receipt and processing of clinical laboratory 
results including an Internet-based architecture.. 

[0021] As illustrated in Fig. 2, a method in a computer system for facilitating the 
process of initiating a callback process is illustrated. The process begins at block 30 by 
publication (or verification) of a clinical laboratory result in the laboratory information 
system (LIS) database. The LIS database is dedicated to the laboratory information system. 
The LIS manages the workflow in the laboratory including the steps around the receipt of 
laboratory results. A clinical laboratory result includes, but is not limited to, numeric and 
codified values depicting the results from clinical laboratory tests such as chemistry, 
hematology, microbiology and blood bank departmental testing. Two well known laboratory 
information systems are the system offered by Cerner Corporation of Kansas City, Missouri 
under the trademark PATHNET and the system offered by Misys Healthcare Systems of 
Raleigh, North Carolina under the trademark MISYS LABORATORY formerly 
SUNQUEST. 

[0022] Once the results are published in the LIS database, at block 34 the laboratory 
results from the LIS database (14 in FIG. 1) are posted to the EMR database (15 in FIG. 1). 
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As known in the art, an EMR database includes clinical event information and other 
information traditional found in a paper-based chart. Typically, clinical events occurring 
throughout the lifetime of the patient are stored in a number of clinical event tables in the 
EMR database. A clinical event includes, but is not limited to documentation of patient 
activities, patient history, discharge summaries, medication administration records, images 
and test results. With reference to FIG. 1, if the LIS database 14 and EMR database 15 use 
similar data formats, then the results posting module 20 writes the laboratory results directly 
to the EMR database. By way of example, the EMR database offered under the trademark 
OPEN CLINICAL FOUNDATION by Cerner Corporation uses a similar data format to the 
LIS offered by Cerner Corporation under the PATHNET trademark. If the LIS database and 
EMR database are foreign to one another and use dissimilar data formats, the information 
from LIS database 14 is published to the EMR database 15 by posting module 20 through an 
interface. As known in the art, one commonly used interface in the health care information 
technology area uses the Health Level Seven (HL7) standard protocol for electronic data 
exchange between computer systems. 

[0023] Once the information is posted to the EMR database, callback initiation and 
documentation processes previously employed within laboratory information systems may be 
used by the EMR system. Specifically, with reference back to FIG. 2, at block 34 the 
callback module evaluates the laboratory results using callback criteria. The callback criteria 
may be based on the ordered procedure, resulted assay, reference range flag, critical range 
flag, ordering physician or ordering location. Other limitations are contemplated as 
mentioned in the background. 

[0024] Next, at decision block 36, the system determines if the result qualifies for 
callback using the evaluation made at block 34. If the result qualifies for callback, at block 
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38 the callback module (22 in FIG. 1) initiates the callback process. In other words, the 
system notifies the user that a callback is required and generates a callback request. Once the 
call is completed, the callback module documents the completion of the call. If the result 
does not qualify for a callback, then a callback is not triggered at block 40. 

[0025] The present invention allows staff outside the laboratory to manage the callback 
process by use of the EMR system and EMR database. Currently, there is a significant 
shortage of qualified laboratory personnel. By distributing the callback responsibilities to 
those outside of the laboratory setting, the laboratory personnel may direct their focus on 
other highly valued activities in the laboratory. Moreover, the system enables automated 
callback identification for laboratory results initially published to a LIS that does not support 
such functionality. This enables laboratory personnel having these types of laboratory 
systems to reap the benefits of automated callback. As such, the benefits and safety of an 
automated callback system may be enjoyed without the expense of replacing existing an 
existing LIS. 

[0026] With reference to FIG. 3, automatically completing a callback request to provide 
notice of laboratory result publication is provided. More specifically, the system and method 
of the present invention manages the actually callback process rather than merely notifying 
the user of the information system that callback is required and documenting when the 
manual callback request is completed by a user. 

[0027] After a callback request is initiated at step 38 from either an LIS database or 
EMR database (according to the method in FIG. 2), the system determines if a user will 
intervene and complete the call back request at decision block 40. In a preferred 
embodiment, one or more laboratory test results requiring callback are presented to the user 
by a graphical user interface. If the user intervenes at block 40 by selection of a callback 
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request, the system presents the user with information required to complete the callback. In a 
preferred embodiment, patient information from the EMR database is provided to the user 
including name, telephone number and patient location. In another alternative, a rule or filter 
may identify certain callback requests so that the requests are only completed manually. 

[0028] Next, at block 42, the system determines if the manual callback of the user was 
successful. Preferably, a graphical user interface prompts the user to provide input when the 
callback is complete. If the callback is successful, at block 42, the user provides input to the 
system documenting that the callback was completed. Preferably, the system records the 
time and date of the completion of the callback and removes the particular laboratory result 
from the queue presented to the user at block 42. This graphical user interface may be 
provided during or after the patient callback information is provided at block 42. If the 
callback is successful at decision block 42, the user provides input that the call was a success 
and provides other pertinent information at block 44 and the callback request is completed 
and stored. 

[0029] If the user does not intervene at decision block 40, the callback request is placed 
in an automated callback request queue at block 48. Next, at regular time intervals, for each 
callback request, the system determines the appropriate method and conditions for callback at 
block 50. The methods of callback include but are not limited to phone, fax, paging, 
forwarding the message via email, or publishing to a system inbox. The method may be 
determined by information relating to the laboratory client, physician, the physician's 
schedule, the available device, time of day or any of a number of other criteria. For example, 
the system may access the physician's schedule to determine if the call should be made to the 
physician's home, the physician's office or any of a number of facilities that the physician 
attends. In another example, the callback may be communicated indirectly to the physician 
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by calling or otherwise communicating the result to the physician's nurse. Also, a number of 
conditions may be applied before allowing a call or other communication to be made. For 
example, a physician may include a condition that no laboratory calls are made from 8:00 PM 
to 8:00 AM. Other conditions that would prevent the call from being made would be based 
on the physician's schedule. For example, if the physician is performing surgery, then no 
calls would be made. 

[0030] Once the appropriate method is determined, the system determines at decision 
block 52 if the conditions for the particular method and laboratory result are satisfied. If the 
conditions are not satisfied, the system may wait until the conditions become satisfied. 
Alternatively, the callback request may be automatically placed back into the automated 
callback queue since the appropriate method for the fulfilling the callback request may 
change before the conditions are completed for the initially selected method. Alternatively, 
the system may hold the request for a particular period of time and wait for the conditions to 
be satisfied. If the conditions are not satisfied in the predefined time period, the requests may 
be routed to the results queue at block 48 or to the beginning of the process at block 38. 

[0031] If the conditions are satisfied, the callback is made at block 54 in accordance 
with the appropriate method determined at block 50. The call or other communication may 
be placed by any of a number of automated technologies known to those of skill in the art. In 
a preferred embodiment, an automated voice response system is employed to complete the 
callback request if the preferred method is telephonic. In this preferred embodiment, an 
identification code or PIN is utilized to identify the party receiving the call to protect the 
potentially sensitive patient information. Next, the system determines if the callback is 
successful at decision block 56. If the callback is successful, the system documents the 
completion of the callback request at step 58. If the callback is not successful at decision 
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block 56, then the callback request is sent to the callback queue at block 48. The fact that the 
initial callback was incomplete is stored at this point. In many cases, an incomplete call may 
change the appropriate method of callback determined at step 50. For example, if the initial 
attempt to call a physician is unsuccessful, then the callback request may be escalated to the 
physician's pager or mobile phone. Further, one or more of unsuccessful attempts by the 
automated system may trigger notification to a person besides the desired recipient of the 
call. In one example, the callback request may be routed to the user of the system and 
required for human intervention. 

[0032] The foregoing description of the invention is illustrative, and modifications in 
configuration and implementation will occur to persons skilled in the art. For instance, while 
the invention has generally been described in terms of a single LIS database 14 which 
communicates with callback module 22 to callback processes, in embodiments more than one 
LIS database may communicate with a central callback module to automate the callback 
process. Other hardware, software or other resources described as singular may in 
embodiments be distributed, and similarly in embodiments resources described as distributed 
may be combined. The scope of the invention is accordingly intended to be limited only by 
the following claims. 



